IBIS Macromodel Task Group Meeting date: 12 June 2018 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Stephen Slater Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft: Walter Katz Todd Westerhoff * Mike LaBonte SPISim: Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Michael M. to prepare a draft BIRD allowing Rgnd and Rpower for the Input Model_type. - Done. - Randy to update the enhanced C_comp Model BIRD draft. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the June 5 meeting. Michael M. moved to approve the minutes. Mike L. seconded the motion. There were no objections. ------------- New Discussion: Enabling [Rgnd] and [Rpower] for Input Model_type: - Michael M: [sharing BIRD draft v1 and reviewing its changes] - Add Rgnd and Rpower to the Input Model_type. - Also some clarifications needed for unambiguous parsing: - Wasn't immediately clear for the normal Terminator if Rac and Cac have to be used as a pair. Added text to clarify this restriction. - Note: v1 contains some inconsistent use of Rgnd, which will be fixed in v2. - Clarify that Rgnd and Rpower can appear in other Model_types in addition to Terminator (i.e. Terminator or Input). - Discussion: Arpad noted that since Rac and Cac are series elements, we had all agreed that you use them as a pair. Michael M. noted that this wasn't explicitly stated, and nothing would stop someone from using an Rac value of zero. Arpad said the keywords are a pair regardless of whether the values are non-zero. Bob agreed with Arpad. With regard to new text explicitly stating that C_comp is required for all [Model]s using these keywords, Bob noted that C_comp is required for all [Model]s except the multi-lingual [External Model]. Bob noted that if we adopt this proposal we still retain the restriction on using Terminator Model_type in IBIS AMI. Therefore, Rac and Cac are still not available for use in AMI Rx devices. Bob noted that he felt Rpower and Rgnd were redundant because they can be handled in the [Pullup] and [Pulldown] tables anyway. Arpad noted the beauty of Rgnd and Rpower was the shorthand. Radek asked what the status of the one-line solution (simply allowing use of Terminator with AMI) for AMI was. Michael M. noted that the alternative solution of adding Rgnd and Rpower to Input was chosen. Radek noted they could be considered two separate issues. Bob said he would not support making both changes, as it would add redundancy multiple ways. Radek said he was fine with the current proposal, but the restriction on Terminator in AMI did not make sense in its own right. Michael M. took the AR to make some fixes and send out v2. Usage Out and Format: - Arpad: [sharing his "Questions about Usage Out parameters" presentation] - First four slides - examples of language in the spec: - page 200 - a Default is not allowed for Usage Out. - Yet on page 196, we explain that Default and Value are mutually exclusive. - So Default and Value are almost synonyms, though on different parts of the tree, in the way they specify a value. - Why is Default explicitly excluded for Out parameters, and not Value? - page 202 - Section states that only In or InOut parameters are going to be part of the string sent to the model. So, we know Out parameters won't be part of that. - page 215 (Jitter parameters): "If these parameters are Usage Out, the EDA tool shall only use the values returned by the AMI_Init function..." - Curtis noted that in this context "shall only use the values returned by AMI_Init" meant as opposed to any values returned by GetWave. Arpad agreed, but said there was still no purpose for the Value provided in the .ami file. - Conclusions slide: - The specification does not say what the EDA tool should do with any Values provided in the .ami file for Usage Out parameters. - "may be ignored" by the EDA tool? - EDA tool shall only use values returned by the model. - If we explicitly exclude Default and Corner, we could just as well exclude Value, Range, List, etc. for Usage Out. - Discussion: Bob noted that he entirely disagreed with the assessment in the presentation. He said a Format specification is required. For Usage Out, the Value of the parameter in the .ami file may be meaningless, but the Format specification provides the context in which values are passed back from the .dll. The Value may just be a placeholder, but it's part of the Format specification. Bob said no rule changes were required. Arpad asked why we have these Values specified if there is no use for them. Radek and Ambrish said they are placeholders. Ambrish said the value might be used if the tool didn't support a parameter passed back from the model. For example, if the range were 0-10 then the .ami file might provide the Value 5 for use by a tool that didn't handle the parameter output from the model. Arpad noted that the spec. did not say this. Ambrish said that was the intent. Ambrish noted that the only issue he saw in the presentation was with the PAM4_LowerThreshold Usage Out example (pg. 235-236), and in that case the example in the spec. is wrong and should be fixed (Value should be added). Bob agreed that it was an editorial mistake, and that example would actually be flagged by the parser as an error. Bob said we wanted to avoid adding more interdependent rules (i.e. Value is required, except for Usage Out), and that it is fine to have a placeholder Value. Arpad said we should at least explain the point that it is merely a placeholder. Arpad noted that he understood Ambrish's interpretation of providing a "default" value. He noted that he had come across a model in which the .ami file specified an Out parameter and the model did not actually return a value for that parameter. Perhaps the model maker had expected the Value in the .ami file to be a default, as Ambrish suggested, but that's not what the spec. says. Curtis noted that he had seen AMI models with the behavior Arpad described, and understood Ambrish's "default" value interpretation. He noted, however, that the spec explicitly states that the model shall return values for all Out (and InOut) parameters (pg. 202 "PROCESSING AND PASSING PARAMETER STRING RULES" - "This string shall contain all of the leaf formatted Usage InOut and Usage Out AMI parameters if there are any defined in the AMI parameter definition file."), so the model in this case was non-compliant. Ambrish, Mike L., and Curtis noted that Range, List, etc. provided some implicit documentation. The tool might give a warning if the model returned a value outside the Range specified in the .ami file. Radek noted the purpose could also be to inform the user. Radek noted that the Format specification is essential in order to parse the output string coming from the .dll. AR: Arpad took the AR to make editorial corrections to his presentation and send it to Mike for posting. Arpad asked everyone to review it and continue the discussion next week. - Ambrish: Motion to adjourn. - Radek: Second. - Arpad: Thank you all for joining. AR: Michael M. to send his "Enabling [Rgnd] and [Rpower] for Input Model_type" v2 for posting. AR: Arpad to send his "Questions about Usage Out parameters" for posting. ------------- Next meeting: 19 June 2018 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives